Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port to .NET Standard #72

Merged
merged 11 commits into from
Apr 18, 2017
Merged

Conversation

nbarbettini
Copy link
Contributor

@nbarbettini nbarbettini commented Mar 28, 2017

This PR makes the project compatible with .NET Standard/.NET Core. You should be able to open and build the new solution with Visual Studio 2017 (Community is fine), or build the project on other platforms with the dotnet tooling.

Here's what I changed:

  • Removed nuget and nuspec. dotnet pack will produce the package now!
  • Targeted .NET Framework 4.5 and .NET Standard 1.3. netstandard1.3 will make this package compatible (see the table) with .NET Framework 4.6+, .NET Core 1.0+, UWP, etc. If Downgrading target framework version to .NET 3.5 #71 is merged, then it should be possible to target .NET Framework 3.5 with the same approach.
  • Moved the tests that require additional dependencies (ServiceStack and System.Web) into a new project. The main test project (now JWT.Tests.Core) is compatible with .NET Core, while JWT.Tests.NETFramework targets the full .NET Framework (because those dependencies are not compatible with .NET Core).
  • Moved the test data that is used by multiple tests into a shared Common project.

All the tests pass! 😄

@nbarbettini
Copy link
Contributor Author

Note: I left the JSON.NET dependency at 9.x. There's a new major version, but I figured that would be better suited for a separate PR.

@abatishchev
Copy link
Member

Awesome! Let me take a closer look once I reach a desktop computer.

Meanwhile can you educate me on target frameworks and net standards. Per #70 and #71 we may want to target .NET 3.5. is it possible with Core?

@nbarbettini
Copy link
Contributor Author

nbarbettini commented Mar 28, 2017

Sure: .NET Standard is the new way of creating portable libraries (it replaces PCLs). When you target a version of .NET Standard (1.2, 1.3, etc), you get an API surface area that is common across multiple platforms. Higher = more APIs = less platforms. So, a library targeting netstandard1.0 has the least APIs available, but is compatible with the most platforms.

You can think of .NET Standard as an interface, which is implemented by the actual frameworks: .NET Framework ("full" .NET), .NET Core, Mono, etc.

This table shows the compatibility matrix. For example, .NET Standard 1.2 is implemented by .NET Framework 4.5.1+ and .NET Core 1.0+. The lowest we can target is 1.3, because the System.Security.Cryptography.Csp package requires 1.3.

Tl;dr - packages created now and in the future should target some level of .NET Standard, preferably the lowest level that still includes the API support it needs. Then it'll be compatible with .NET Framework, .NET Core, future versions of Mono/Xamarin, future frameworks, etc.

@nbarbettini
Copy link
Contributor Author

Re: .NET 3.5 (To add some more complexity to the topic... 😄 )

You'll notice that the table I linked to only shows .NET Framework down to v4.5 (which implements .NET Standard 1.0 and 1.1). This means that a library built to target netstandard1.1 would be usable in a .NET Framework 4.5 project, for example.

For .NET Framework compatibility <4.5, you have to "multi-target" your project and build a separate binary for those framework versions. It's confusing at first, but it works. In this PR, I targeted netstandard1.3 and .NET Framework 4.5. We should be able to drop that down to .NET Framework 3.5 without any problems. I'll test it in a bit.

@nbarbettini
Copy link
Contributor Author

See my new commit - this should now be compatible with:

  • .NET Framework 3.5+
  • .NET Standard 1.3+ (.NET Core, UWP, Xamarin)

I had to remove Lazy<> like #71.

@abatishchev
Copy link
Member

Thanks for great explanation! I'm mostly old/full .NET guy. Got sick with all this PCL crap that don't want to touch it now. And don't have much need too.

Yes, let's target 3.5 in Full .NET mode and the lowest possible in NetStandard.

I was thinking to make few child packages: one that depends on Json.Net to remove this dependency from parent package, and now maybe one that depends on cryptography if this would allow to lower target NetStandard?

@nbarbettini
Copy link
Contributor Author

No problem 👍 It took me a while to wrap my head around the new world. It's complex at first, but no more PCLs!

one that depends on Json.Net to remove this dependency

Who would use this? People who want to bring their own IJsonSerializer I guess?

@nbarbettini
Copy link
Contributor Author

I could see some benefit of splitting the package up into child packages. I think that might be out of scope of the PR though, happy to address that in a separate one 👍

@abatishchev
Copy link
Member

To discuss the split #76

@paddyfink
Copy link

Hello, I tried to use this library https://github.com/viniciusmelquiades/jwt which is a fork of this one but I got this message when I try to encode a jwt : You need to set a JSON serializer. You only need to do this once.
Does it have something to do with the IJsonSerializer you are talking about?

@abatishchev
Copy link
Member

@paddyfink hi, please open another issue, will discuss it there.

@nbarbettini
Copy link
Contributor Author

@abatishchev Any changes you need on this before merging? (other than resolving the nuspec conflict)

@abatishchev
Copy link
Member

Hmm, is there a way it to work in VS2015? Currently I'm getting an error opening projects:

D:\Projects\Open Source\Jwt-nb\src\JWT\JWT.csproj : error : The default XML namespace of the project must be the MSBuild XML namespace. If the project is authored in the MSBuild 2003 format, please add xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the element. If the project has been authored in the old 1.0 or 1.2 format, please convert it to MSBuild 2003 format. D:\Projects\Open Source\Jwt-nb\src\JWT\JWT.csproj

D:\Projects\Open Source\Jwt-nb\tests\JWT.Tests.Common\JWT.Tests.Common.csproj : error : The default XML namespace of the project must be the MSBuild XML namespace. If the project is authored in the MSBuild 2003 format, please add xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the element. If the project has been authored in the old 1.0 or 1.2 format, please convert it to MSBuild 2003 format. D:\Projects\Open Source\Jwt-nb\tests\JWT.Tests.Common\JWT.Tests.Common.csproj

D:\Projects\Open Source\Jwt-nb\src\JWT\JWT.csproj : error : The default XML namespace of the project must be the MSBuild XML namespace. If the project is authored in the MSBuild 2003 format, please add xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the element. If the project has been authored in the old 1.0 or 1.2 format, please convert it to MSBuild 2003 format. D:\Projects\Open Source\Jwt-nb\src\JWT\JWT.csproj

Or I just don't have the latest Core tooling installed?

@abatishchev abatishchev added this to the 2.0 milestone Apr 3, 2017
@nbarbettini
Copy link
Contributor Author

nbarbettini commented Apr 3, 2017

The new project format requires VS2017 as far as I know. I've been using the free Community Edition: https://www.visualstudio.com/downloads/

@abatishchev
Copy link
Member

Bummer. And might be quite inconvenient not just to me but to other people too. Can you please double check? Should be a way to make it work in VS2015? I haven't heard this is a well-known limitation of new Core tooling. However still might be it.

@nbarbettini
Copy link
Contributor Author

Yeah, unfortunately that is the case. The new project system (csproj tooling for .NET Core/.NET Standard) requires VS2017. However the project can still be built on the command line (without VS) using dotnet.

How do you want to proceed?

@abatishchev abatishchev modified the milestones: 3.0, 2.0 Apr 8, 2017
@abatishchev
Copy link
Member

As I saw in other OSS projects her eon GitHub, I'm not alone in this kind of struggle. Let me install VS2017 on my machine, try and let you know, we'll merge it it. Can I ask for a favor and meanwhile resolve the conflicts?

@nbarbettini
Copy link
Contributor Author

I rebased this against master. It should be totally up-to-date with the latest changes you pushed for v2.3. (If I missed something, let me know!)

I changed the version to 3.0.0-beta1.

@abatishchev
Copy link
Member

Current status: installing VS 2017 :) Sorry to make you waiting on this.

@nbarbettini
Copy link
Contributor Author

Sorry to make you waiting on this.

No problem at all, I've been too busy to look at it these past few days anyway. 😄

@abatishchev
Copy link
Member

Can you please push the branch to this repo rather then yours? Or we'll have to recreate the pr?

@abatishchev
Copy link
Member

Yes, seems so. I can change the base but can't change the source.

@abatishchev
Copy link
Member

I'm asking because GitHub (at least to my knowledge) makes in non-trivial to clone source repo/branch where the pr from created from.

@abatishchev
Copy link
Member

I got it https://github.com/nbarbettini/jwt/tree/netstandard but again it wasn't trivial like a direct link from pr's page

@nbarbettini
Copy link
Contributor Author

Yeah, it's a little awkward. AFAIK the best way to checkout a remote fork PR is to check out that repo.

@abatishchev
Copy link
Member

Looks good!
Just few things annoys me (unrelated to the changes):

  • Had to restart VS so NuGet could properly restore packages (usual thing)
  • StyleCop warning "Missing XML comment for publicly visible type or member". I can't ask you to spent time on this but not willing to spent my time either, hate to do this :)

@abatishchev
Copy link
Member

Should we rename/lower-case JWT.Tests.NETFramework to NetFramework?

@abatishchev abatishchev merged commit a2f104d into jwt-dotnet:master Apr 18, 2017
@abatishchev
Copy link
Member

Yay! Thanks a lot for this work!!

@nbarbettini nbarbettini deleted the netstandard branch April 19, 2017 17:50
@nbarbettini
Copy link
Contributor Author

StyleCop warning "Missing XML comment for publicly visible type or member"

I think it's only a few members that need XML comments. I can add them later. 👍

Should we rename/lower-case JWT.Tests.NETFramework to NetFramework?

Doesn't matter much, but "NETFramework" is/was used in the context of TFMs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

None yet

3 participants